Why ideate?
Over the 2 years that we've been working on the Figma plugin, we've heard a lot of feedback and suggestions about how we could better integrate FireJet into their workflow. Now that we are at satisfactory level in terms of addressing our main feedback (i.e. code quality), we are ready to explore other our users' suggestions on full-on Figma-to-code integration.
Customer Needs
We've been reaching out and talking to developers and designers for two weeks now. And we have some made some learnings:
- For simple websites, teams may use a no-code tool, but for complex web apps, coding from scratch is necessary. This is an absolute requirement.
- Designers prefer to use Figma for their design work regardless of the type of project they are working on.
- Designers often experience friction between design and code when the final product created by the developer does not closely resemble their original design.
- Developers often have limited flexibility to make UI changes for the designer as they are typically occupied with implementing core features.
- Developers generally dislike meetings.
- Smaller companies strongly insist on using Figma for design purposes.
- As companies grow larger (after series B funding), they start utilizing their own design systems.
- Changes to design systems are typically initiated at the beginning of projects during monthly client meetings or user interviews.
- Changes to design systems often involve updating existing components rather than creating new ones from scratch.
I won't say the list above is completely true, and I may have made mistakes in my observation of the market space. Feel free to reach out to me if you feel differently!
User Profile
In the design-to-code space, there are 3 parties affected. From our learnings, here are their needs:
Product Manager / CPO / etc
PMs spend a lot of their budget on hiring frontend developers to convert designs into code. They will look for tools to accelerate this process for their developers, especially if it can accelerate their product development time and/or reduce their development cost. They also talk frequently to their clients and customers, who often request changes to the product during the development process. These changes have a need to be done immediately. As such here are their needs:
Designers
Designers are the creative brain of the project. They need the flexibility of Figma to turn their inspiration into reality over the constraints of no-code builders. Also as mentioned earlier, the final product rarely looks like their initial design. This is a pain point. As such, here are their needs:
Developers
The brawn of the project, developers are always busy. Their primary task for design-to-code is the manual process of converting Figma designs into frontend code. They have specific requirements on the code generated based off the exisiting technology (i.e. frameworks, language, coding practices) they use.
As such, here is a breakdown of their needs:
| 📦 Product Manager | 🎨 Designer | ⌨️ Developer |
|---|---|---|
| Save time and cost of development | New tools must be in Figma | Responsive and readable code |
| Make changes to product easily | Final code must render pixel-perfect with respect to their initial design | Framework agnostic |
Possible Solutions
Ideal Workflow
The ideal workflow for users is: Figma ⇋ Code
People intuitively expect the code to be in sync with their designs. But Figma is a designer-first tool that was never built for code conversion. As such, we have to come up with creative ways to get past this barrier. We've come up with several workflows:
Workflow 1 - Figma as the source of truth
Your Figma is completely synced with an auto-generated design system. Any changes made to Figma components are updated in your code. There is a Figma plugin interface to handle responsivenes, component props, behaviours, and design system documentation.
Main Value Proposition: Saves the developer time in maintaining the design system
Steps:
- Designer creates design system in Figma (like you would in any other Figma project)
- Designer adds in responsivenes, component props, behaviours, and documentation via an interface
- A documentation page is automatically generated for the design system at a URL (e.g. abc-design-system.com)
- Developer imports components from design system into code (e.g. yarn add @abc-design-system)
Workflow 2 - Design system as the source of truth
Your design system stays as it is. You are able to import your design system components into your Figma project. When the code is generated, the algorithm uses the code from the original design system. There is also a Figma plugin interface to decide the variant and properties you want to set before you import.
Main Value Proposition: Almost zero design-code leakage means less back and forth between designer and developer
Steps:
- Designer imports design system into Figma plugin
- Designer drags and drops the exisiting components into Figma as they see fit
- Developer generates code to use as they see fit
Workflow 3 - Design ⇋ Code Platform with Import from Figma
A design and code platform where design and code are in sync. You can edit designs to change the code. You can edit code to change the design. You can also import designs from Figma. It's literally a Figma with a code editor. This actually already exisits as our second product that is in beta: FireJet Sync. We just need to fix the bugs.
Main Value Proposition: Zero design-code leakage (if you keep your designs on the platform) means no more back and forth between designer and developer
Workflow 4 - Figma ⇋ Code conversion API
Conversion API for converting Figma designs into code and vice versa. Teams can built their own custom implementation of solving their specific design-to-code problems using the conversion API.
Main Value Proposition: Full-flexibility on solution implementation